<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
    <title>Inversion of Control History</title></head>


<body>
<p>Here is some of the history of the pattern or principle known as
    Inversion of Control (IoC). There is some confusion online as to
    whether IoC has been renamed Dependency Injection (DI). This is not the
    case, DI concerns just one aspect of IoC - component assembly. The
    other two are configuration and lifecycle. </p>

<p>See also the <a href="comparisons.html">comparisons</a> page. </p>

<h2>Avalon</h2>

<p>Inversion of Control, as a term, was popularised in 1998 by <a href="http://www.betaversion.org/%7Estefano/">Stefano
    Mazzocchi</a>
    as consequence of trying to engineer a 'Java Apache Server Framework'
    for the growing set of server side Java components and tools at <a href="http://www.apache.org/">Apache</a>.
    Sun were just starting to protect the word Java when used for
    branding/naming of software and computing functions, so Apache had to
    look for alternative names. Avalon was chosen as a project name (queue
    images of <a href="http://en.wikipedia.org/wiki/Avalon">Arthurian legend</a>).</p>

<p>To the Avalon team, it was clear that components receiving various aspects of <strong>component assembly</strong>,
    <strong>configuration</strong> and <strong>lifecycle</strong> was a superior design to those components going at
    getting the same themselves. </p>

<p>It is important to point out that The Open Services Gateway (OSGi)
    initiative was also started around the same time as the Avalon
    framework and was similar to a degree. It was born in Europe and
    specified/controlled by a foundation formed around it.&nbsp; </p>

<p>Latterly this type of IoC has been given a new name - Contextualized Dependency Lookup.</p>

<p>Avalon was cancelled as an Apache project in 2004, by the Apache Software Foundation.</p>

<h2>Setter Injection</h2>

<p><a href="http://joe.truemesh.com/blog/">Joe Walnes</a>, <a href="http://joe.truemesh.com/blog/">Mike Cannon
    Brookes</a> and others found themselves writing <a href="http://www.opensymphony.com/xwork/">XWork</a> and <a
        href="http://www.opensymphony.com/webwork/">WebWork2</a> to support their forthcoming book, <a
        href="http://www.amazon.com/Java-Open-Source-Programming-Hibernate/dp/0471463620">Java Open Source
    Programming</a>.
    Joe pointed out that the concepts were very much like those from
    IoC/Avalon that Paul had been trying to convince Joe to adopt for a
    couple of years, but that dependencies were passed into the component
    via setters. The need for those dependencies was declared in some
    accompanying XML.</p>

<p>Paul who worked with Joe at an energy trading company in London,
    suggested this was a &quot;second type&quot; of Inversion of Control. Type two IoC, as a
    term, has been obsoleted for "Setter Injection" of course. </p>

<p><a href="http://blog.interface21.com/main/author/rodj/">Rod Johnson</a>, lead for the <a
        href="http://www.springframework.org/">Spring Framework</a> wrote a book <a
        href="http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764543857.html">Expert One-on-One J2EE Design and
    Development</a>
    (published Oct 2002) that also discussed the concepts of setter
    injection, and introduced the codeline that ultimately became the <a
        href="http://sourceforge.net/projects/springframework">Spring Framework</a> at SourceForge in February of 2003.
</p>

<p>Martin Fowler has suggested that it may be better to have such
    dependency resolving methods prefixed with init rather than setter.
    With init or set prefixes to dependency receiving methods, a container
    could automatically assemble SDI components without the manifest. SDI,
    under container control, works best with the manifest though. Without a
    container, SDI Components are very much like simple Java beans to use:</p>

<p>A downside of direct bean user of an SDI component is that it is
    possible to instantiate a component without setting all the
    dependencies. As mistakes, these should be quite quick to catch
    post-compile with a simple test of that application. Months later
    though, when a jar of components is replaced in an application with a
    latter version of the same, a new dependency may be missed, and a
    non-functioning application may be shipped to live. Again, that could
    be caught with diligent testing.</p>

<h2>Constructor Injection </h2>

<p>Rachel Davies, as one of the enthusiastic reviewers of Joe's book,
    left a margin note for the paragraphs that discussed the elegance of
    type two. The margin-note simply suggested that resolving dependencies
    by constructor was more elegant. Latterly we are inclined to agree. At
    that moment in time (the spring of 2003) there were no implementation
    of the constructor injection idea, so it seemed logical for the initial
    PicoContainer leads (Paul Hammant and Aslak Hellesoy) who liked the
    idea, to kick off the project.</p>

<p>The added advantage is that CDI Components cannot be instantiated
    with missing dependencies. Thus the compiler or IDE will catch
    mismatches between any constructor and the parameters passed into the
    class on instantiation.</p>

<p><a href="http://www.atg.com/en/company/dynamo.jhtml">ATG Dynamo</a>
    was a commercial product that was successful in the market place in the
    late 90's. It also used constructors for dependency resolution.
    Dynamo's commercial success yielded a little when Apache made Struts,
    but it should not be forgotten that Dynamo casually used constructors
    for dependencies in web-applications first. </p>

<h2>Types 1, 2 &amp; 3 renamed </h2>

<p>In 2003, Paul was refering to the Avalon style of IoC as "type 1",
    setter as "type 2" and constructor as "type 3". He went as far as
    publishing an <a href="http://java.sys-con.com/read/38102.htm">article</a> on it in Java Developer Journal. </p>

<p><em>December 2003</em>; Rod Johnson of the Spring Framework team,
    Paul Hammant (former Avaloner, and co-lead of PicoContainer), Mike
    Royle, with Martin Fowler (by email) say down and played with some of
    the language of Martin's forthcoming article. Martin had drafted this
    article entirely independently of this team but had be kind enough to
    show a draft to them. The problem the team had was with the naming of
    the patterns related to Inversion of Control, and the examples of use
    that Martin had shown. Rod had been using the injection phrase before
    so it was felt that the component resolving style being "Dependency
    Injection" would be a good thing. </p>

<p>Thus when Dependency Injection rightly took over:</p>

<blockquote>
    <p> Type 1 becomes Contextualized Dependency Lookup<br/>
        <br/>
        Type 2 becomes Setter Dependency Injection<br/>
        <br/>
        Type 3 becomes Constructor Dependency Injection</p>

    <p>Type 4 was Field Injection or getter injection depending on who you spoke to. </p>
</blockquote>
<h2>Timelines</h2>

<p><img src="images/ioc-timeline.png" alt="timeline picture" height="347" width="691"/></p>

<h2>Prior Art</h2>

<p>As a concept, Inversion of Control was not entirely new when
    Steffano popularised it at Apache in 1998. Parts of it been talked
    about before as Dependency Inversion Principle (Bob Martin) and the
    'Hollywood Principle' (don't call us, we'll call you), and the term
    cropped had been cropping up since 1996. </p>

<p>Gang of Four, <a href="http://en.wikipedia.org/wiki/Design_Patterns">Design Patterns</a>, 1994 "Hollywood Pattern"
    (don't call us, we'll call you) as discussion point on 'Template' Pattern. </p>

<p>Robert C. Martin, "Dependency Inversion" in posting on comp.lang.c++, August 1994: <a
        href="http://groups.google.com/group/comp.lang.c++/msg/b9c929f55c52e4a2?">OO Design Quality Metrics: An Analysis
    of Dependencies</a></p>

<p>Robert C. Martin, : "Principle of Depenency Inversion" in posting on comp.lang.c++, June 1995: <a
        href="http://groups.google.com/group/comp.lang.c++/msg/30f7c7701209faba?dmode=source">The Principles of OOD</a>
    with follow up postings through July 1995 </p>

<p>Robert C. Martin, The Dependency Inversion Principle, In: C++ Report, Vol. 8, May 1996. See more recent <a
        href="http://www.objectmentor.com/resources/articles/dip.pdf">PDF</a></p>

<p>Michael Mattesson, 1996, <a
        href="http://web.archive.org/web/20000815083810/www.ipd.hk-r.se/michaelm/thesis/toc.html">Object-Oriented
    Frameworks : A survey of methodological issues</a> "inversion of control" used in passing. </p>

<p>Brian Foote and Joseph Yoder, June 1998. <a href="http://www.laputan.org/mud/">Big Ball of Mud</a>. Not so much on
    IoC, but setting the scene. </p>

<p>Ralph E. Johnson and Brian Foote, June 1998, <a href="http://www.laputan.org/drc/drc.html">Designing Reusable
    Classes</a> "inversion of control" used in passing. </p>

<p>&nbsp;</p>
</body>
</html>